緣起

我在實作微服務流程（例如付款→送餐的兩步驟）時，總是反覆碰到相同類型的問題，歸納如下：

• 現實挑戰

  • 連線瞬斷、暫時性錯誤
  • 下游拋錯（例：信用卡過期）
  • 服務維護或臨時故障

• 必備能力與配套

  • 失敗復原與狀態持久化
  • 可觀測性與警示（指標、日誌、追蹤）
  • 分散式交易正確性：冪等、逾時、補償
  • 跨天期長流程的持續執行與可追蹤性

• 複雜度成長

  • 每新增一個步驟，錯誤組合呈倍數上升
  • 不只要把「主任務做完」，還要設計流程與平台能力

光看這些我自己都 PTSD 了，即使流程簡單到只有兩個步驟，這些重複出現的痛點，促使我想去研究還有什麼可以讓事情變得簡單！

分散式架構的核心目標是什麼？

回到最初，為什麼要用到分散式架構呢？一般來說需要用到的情境有以下這些：

• 自治與可演進性: 架構能支援團隊規模擴大與功能拆分，降低跨團隊耦合。
• 資料在地化/合規: 支援不同國家或區域的法規（如：會計法規、金融規範）。
• 成本效益: 根據負載自動擴縮，避免過度資源浪費。
• 邊緣運算: 系統本身分散在各端點，期望快速回應使用者需求。
• 高可用與故障隔離: 局部失效不應拖垮整體服務；支援自動復原與容錯機制。
• 性能優化: 能隨著使用者數或資料量成長，自動水平擴充，不需大改架構。

每個專案或產品的需求不一定相同，最好先釐清一下目標為何？不同的答案，就會帶出不同的設計與取捨。
以下先介紹三種常見的處理手法 Basic Retry, Job Scheduling, Event Driven Architecture！

常見處理手法的邊界與代價

Basic Retry

• 特性: 單純的同步請求內重試；常見搭配逾時、指數退避與抖動；要求操作具備冪等性以避免副作用重複。
• 使用情境: 短週期的 API 呼叫，短暫性錯誤（暫時性網路抖動、503/429）、下游偶發延遲。
• 誤用: 對非暫時性錯誤（4xx/業務拒絕）盲目重試；在整個依賴樹上同時重試導致放大效應。
• 陷阱: 重試風暴、雪崩效應、排隊延遲累積；逾時大於下游逾時造成資源佔用；缺乏冪等鍵導致重複寫入。
• 導入複雜度: 低，可引入相關套件，如：Resilience4j，簡化設定。
• 維護複雜度: 低到中；需持續調整逾時、重試次數等；但實際狀況不容易管理，
• 可觀測性: 需有重試次數、原因、最終成功/失敗率與尾延遲指標；分散式追蹤要保留相同 Trace/Span 以關聯嘗試。
• 流程可見性: 低；重試發生在單次請求內，缺少跨流程視角。

Job Scheduling 排程

• 特性: 非同步背景工作；由排程器產生工作；常見批次處理；多為至少一次語義，需由業務邏輯保證冪等。
• 使用情境: 長時間或可延後的任務（重試延遲、轉檔、報表產生、資料清理）
• 誤用: 用排程串接多個強相依步驟而不保留狀態機，造成隱性編排。
• 陷阱: 重複排程、時鐘漂移、單點排程器、觸發延遲不即時、Job 與程式碼脈絡斷裂。
• 導入複雜度: 中；需工作者與排程器。
• 維護複雜度: 中；需處理併發、重試策略、隔離資源池、排程、處理失敗重試等。
• 可觀測性: 手動撰寫追蹤 job 狀態（排隊、執行、成功、失敗）、重試次數、等待時間；可串接追蹤以跨服務關聯一次執行。
• 流程可見性: 中；若有儀表板與狀態機，能清楚查看每個 job 的生命週期。

排程最讓我挫折的是用來串接流程，不僅在 cron 的設定上傷透腦筋，觸發不即時且有一定的資源浪費；流程程式碼上下文斷裂更令人抓狂。

Event Driven Architecture 事件驅動架構

• 特性: 解耦合生產者/消費者；常見至少一次遞送與最終一致；需治理事件模式（schema）。
• 使用情境: 高頻事件流（IoT、交易、日誌管線）、Fan-out 廣播型通知、跨服務資料同步。
• 誤用: 把事件當命令（期望立即執行與回應）；對強一致需求誤以為「一次且僅一次」可輕易達成。
• 陷阱: 重複事件與亂序、消費者延遲與落後（lag）、事件爆炸與版本治理困難、隱性耦合。
• 導入複雜度: 中到高；需建置 broker（Kafka/RabbitMQ 等）。
• 維護複雜度: 高；需要清楚的事件命名、版本策略、冪等/去重策略、順序設計等。
• 可觀測性: 監控主題吞吐、延遲、消費者 lag、DLQ；事件流追蹤與資料沿革（lineage）；端到端追蹤需傳遞 correlation/trace id。
• 流程可見性: 中到高；若建立事件流可視化與審計軌跡，能精準回放與調查，但需要平台投資。

EDA 最常提倡的是『解耦』，這讓工程師趨之若鶩，殊不知它僅僅是做到時間解耦罷了，又引入了我稱之為文件耦合或者知識耦合的管理問題；並且因為建立了 Message Queue 的基礎設施而增加維運的複雜度，但相關的冪等性及順序性等問題都沒減少！可實際上 EDA 的使用情境其實相對狹窄(如前述）。

結論

前面提到的各種處理方式雖然各有其適用情境，但往往也容易被誤用。

相比之下，我認為流程引擎的應用範圍更廣，能提供更完整的解決方案。雖然一開始的學習曲線偏高，但長期維護成本會趨於穩定，開發者的心智負擔也不會隨著系統複雜度而急速上升。更重要的是，流程引擎在多數分散式需求上都能對應處理。

因此，下一篇我們就來討論流程引擎吧！